From: Gunther Schadow [gunther@aurora.regenstrief.org]
Sent: Friday, May 30, 2003 8:12 AM
To: Karen VanHentenryck (HL7)
Cc: mnm@lists.hl7.org; Lloyd McKenzie; Dale Nelson; Norman Daoust;
ShakirConsulting@cs.com
Subject: Re: Proposed RIM/vocabulary changes

Folks, since I have to be at an important finger-printing appointment with the INS, I will not be able to attend the conference call today. I have, however, read through the proposals and will look forward for amendments to cast a final O.K. I only have two issues with any of this
now:

- Lloyd proposed to delete the ControlAct.responseCode. THIS SHOULD NOT
   BE DONE NOW. The Lab Automation group backed by the general Orders/
   Observations committee consciously put this attribute in. It may be
   disputable, but it can't be shot down from the hip. Lloyd says:

"This attribute should never have been created.  The responsibilities of 
the receiver are defined by the receiver responsibilities associated 
with the interaction.  The sender is not allowed to change them on the 
fly.  Furthermore, if an attribute like this were to be supported, it 
should be placed on the Message, not on the ControlAct.  The ControlAct 
can appear in numerous contexts, including within structured documents, 
as part of message payloads, etc. where the idea of a "response" is 
completely meaningless.  The only thing that can have a response is a 
message.  If we want to control the response, we need to indicate that 
on the Message."

   And I am sympathetic to his issue on receiver responsibility although
   I am not convinced. But I do not agree at all to the issue of message.
   The message wrapper is ONLY for transport behavior and should have NO
   bearing on the Application-Layer actions (which includes what payloads
   are generated in responses.) So, if this is anywhere, it is in the
   ControlAct (just to avoid moving it into the general Act, which I am
   sure Lloyd will not prefer ;-). If we find we can obsolesce this
   later, fine, but we don't have to delete it on the fast track.


- Dale's override observation proposal surprizes me because I had hoped
   that we will move away from it. I thought Pharmacy and Finance
   modeling would not use it any more and instead use the Issue acts
   (sort of like diagnoses, stating what's wrong, ERROR and WARNING
   issues as they occur in technical specifications are also included
   here.) Overrides would be separate acts in response to issues. An
   override is just one form of reponding to an issue.

   I have never agreed to the use of Observations to communicate just
   any variable=value information. An override is anything BUT an
   observation. An override is more a command. While the definition
   of Observation has a weasle-out clause, this is only to accomodate
   the ad-hoc needs of people in the field, we should not give that
   bad example in the very core of HL7.

   So, I am opposed to anything that's expanding on that Observation
   theme for overrides. (Observation for the ISSUEs, diagnoses, warnings,
   errors, etc. is O.K., but NOT for the override ACTION or COMMAND.)


- Norman's acuityLevel proposal: Friendly ammendment: please spell
   out the abbreviation "RBS" and if possible provide reference to its
   specification.

   Unfriendly (but not pertinent) comment: since I bet this is a score
   derived from some basic observations, would be much better to send
   in an observation, just like you send diagnoses in Observations.
   This comment is not new and it doesn't really influence the definition
   change proposal. But if you do consider disputing the attribute,
   then consider turning it into an observation. That way you can
   actually document how you assigned this code.


regards
-Gunther



Karen VanHentenryck (HL7) wrote:
> Proposed changes to the Reference Information Model/Vocabulary have 
> been
> received from various committees.  The submissions can be accessed at:
> 
> http://www.hl7.org/library/committees/mnm/rim.cfm
> 
> The proposed changes will be included in the harmonization discussions
> 
> to be held on the MnM conference call on May 30.  To participate in this 
> call, dial 703-788-0600 and enter passcode 236177#.   
> 
> Any comment you may have in support or opposition to the proposed
> changes may be addressed to the MnM list or directly to the MnM 
> Co-Chairs: Woody Beeler,  Beeler Consulting LLC  (507) 254-4810 Email: 
> woody@beelers.com;  Abdul-Malik Shakir, Shakir Consulting,  (909) 
> 596-6790   Email: shakirconsulting@cs.com; or Jane Curry, Sierra Systems 
> -  Phone:  (780) 424-0852  Email: janecurry@sierrasystems.com
> 
>  
> 
> ---
> To access the Mailing List archives, go to: 
> http://lists.hl7.org/lyris.pl?enter=mnm


-- 
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org



---
To access the Mailing List archives, go to: 
http://lists.hl7.org/lyris.pl?enter=mnm

